home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv2.zip / V2N84.TXT < prev    next >
Text File  |  1993-03-29  |  16KB  |  375 lines
  1.  
  2.  
  3.  
  4.  
  5. Ultrasound Daily Digest     Mon, 29 Mar 93       Volume 2 : Issue  84 
  6.  
  7. Today's Topics:
  8.                             FTP SITE ADMIN
  9.                           GMOS Mailing List
  10.                        honesty vs salesmanship
  11.                            IRC discussions
  12.                 Miditest.exe: MIDI port tester on epas
  13.                               More GMOS
  14.                            mt32.zip on epas
  15.                      Ultrasound Daily Digest V...
  16.                     Ultrasound Daily Digest V2 #83
  17.                        Zone 66 - Parity Errors
  18.  
  19.     Information about the UltraSound Daily Digest (such as
  20. mail addresses, request servers, ftp sites, etc., etc.) can be found
  21. at the end of the Digest.
  22.  
  23.     *** HEY!!! *** 
  24.  
  25.     Before you ask a question, *** READ THE FAQ ***.  It's
  26. available on the request server and the ftp sites, or check the
  27. newsgroup archives.
  28.  
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Sun, 28 Mar 93 20:03:36 MST
  32. From: ddebry@itchy (Dave DeBry)
  33. Message-Id: <9303290303.AA05811@itchy>
  34. Subject: FTP SITE ADMIN
  35. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  36.  
  37.     The digests up through v02i83 have been uploaded to epas.
  38.  
  39.     Remember that we go to v03 on April 1st (no joke! :) .
  40.  
  41.  
  42. -- 
  43. Dave  ddebry@ debry@   \ "All this has been removed for the last 48 hours
  44. DeBry dsd.    peruvian. | and I have a doctor prodding the angry swelling
  45.       es.     cs.utah.  | on my porch."
  46.       com     edu      /  
  47.  
  48. ------------------------------
  49.  
  50. Date: Sun, 28 Mar 93 19:40:08 MST
  51. From: ddebry@itchy (Dave DeBry)
  52. Message-Id: <9303290240.AA05404@itchy>
  53. Subject: GMOS Mailing List
  54. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  55.  
  56.  
  57.  
  58.     There has been a lot of volume about the "GMOS" concept
  59. lately, with a potential for a lot more.  So, I've created a GMOS
  60. mailing list.  It's a reflector, but like the other reflectors, it may
  61. become a digest if the readership and volume go up enough.
  62.  
  63.     Mail to:  gmos-request%itchy@dsd.es.com  to subscribe.
  64.  
  65. -- 
  66. Dave  ddebry@ debry@   \ 
  67. DeBry dsd.    peruvian. | "They sent the chicken bone to the lab.  It
  68.       es.     cs.utah.  |  came back 'chicken bone'."
  69.       com     edu      / 
  70.  
  71. ------------------------------
  72.  
  73. Date: 29 Mar 1993 16:01:28 +1000
  74. From: PHTH1@cc.newcastle.edu.au
  75. Message-Id: <01GWDWRMO7HU9LYKE9@cc.newcastle.edu.au>
  76. Subject: honesty vs salesmanship
  77. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  78.  
  79. Regarding the line, "being overly critical of a $150 sound card"...
  80.  
  81. Thank you to the Gravis rep for all that information. It is most useful,
  82. and also very encouraging to have official representation on the public
  83. network. As far as the quoted remark is concerned, I for one am far more
  84. impressed by honesty than propaganda. The fact that you guys are prepared
  85. to (a) face up to the problems, and (b) do something about them, inspires
  86. far more confidence in me than the typical line, "Our product is the 
  87. absolute best, it has no problems, it will never break, it works with
  88. everything" etc. etc. etc.
  89.  
  90. Thanks again for a great sound card, and for the after-sales support.
  91.  
  92. Tony
  93.  
  94. ------------------------------
  95.  
  96. Date: Sun, 28 Mar 93 09:41:22 +0200
  97. From: Shmuel Gazit <keeper@ccsg.tau.ac.il>
  98. Message-Id: <9303280741.AA12464@ccsg.tau.ac.il>
  99. Subject: IRC discussions
  100. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  101.  
  102. Hello GUSers !
  103.  
  104. I've seen some ppl here talking about a discussion in a Newsgroup.
  105. While this can be nice, I want to suggest another idea - since many
  106. of us are on internet, why not use IRC (Internet Relay Chat system)
  107. for online discussions ? we are on different time zones, thats true,
  108. but I'm sure it can help in developing and just chatting..
  109. If u don't know how to get on the system, ask somebody who knows
  110. how to connect (your Admin, someone at the CC, etc..)
  111.  
  112.  
  113. if u do enter, and look for a channel - enter #GUS 
  114.  
  115. c u all there :)
  116. /Shmulik.
  117.  
  118. ------------------------------
  119.  
  120. Date: Sun, 28 Mar 93 23:52:02 WET
  121. From: dp@hydra.carleton.CA (Dave Perry VE3IFB)
  122. Message-Id: <9303290452.AA09055@hydra.carleton.CA>
  123. Subject: Miditest.exe: MIDI port tester on epas
  124. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  125.  
  126. I have put miditest.zip on archive.epas.utoronto.ca.  This is a program
  127. to monitor the midi input.  I know something like this already exists,
  128. but I could only find one for Windows, not DOS.  This program runs in a
  129. DOS session, which is handy when you aren't sure whether your Windows
  130. installation is correct.
  131.  
  132. Enjoy.
  133.  
  134. Dave Perry
  135. dp@hydra.carleton.ca
  136.  
  137. ------------------------------
  138.  
  139. Date: 29 Mar 1993 01:17:16 +0800
  140. From: TC <SH7126146@NTUVAX.NTU.AC.SG>
  141. Message-Id: <01GWD22SBOG2A9LIX1@NTUVAX.NTU.AC.SG>
  142. Subject: More GMOS
  143. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  144.  
  145.  
  146. > Actually it doesn't even require the cooperation of the conpanies.  I am
  147. > sure there are more than a few hackers out there, who could decipher the
  148. > GM instructions in games, and make a "patch" for such games to remap the
  149. > whole game to 1meg worth of patches.
  150.  
  151. I wonder why no one caught the reference to option (3) which I mentioned
  152. should allow GMOS to determine the patch changes during a particular
  153. run. For example, you run 'GMOS -cxwing.cfg' and GMOS will collect any
  154. MIDI patch change information throughout this particular session and
  155. save it to a .cfg file. It can then load this file later to load the
  156. required patches. Of course, this is not fail safe. A program might need
  157. more than 1MB worth of patches throughout the whole run. Thus, dynamic
  158. loading will STILL have to be supported.
  159.  
  160. This way we won't see people posting 'does anyone have a patch map for
  161. so-and-so game?'. They can do it themselves.
  162.  
  163. > Also, as far as dynamic patch loading goes, this would take some pretty
  164. > smart coding, or else how would the GMOS know which patches to clear to
  165. > make room for the new patches.  The one used least frequently?  The largest
  166.  
  167.  
  168.  
  169. You have to trade off something for this dynamic loading method. The
  170. simplest way would be in terms of the oldest patch that has not been
  171. accessed (this means it assumes that the program no longer needs that
  172. patch since it has not used it for a long time).
  173.  
  174. The problems with this is mainly in management of the GUS memory.
  175. Allocating and deallocating patches dynamically creates "holes" in the
  176. memory map of the GUS, and since a patch has to be sequential, either we
  177. have to 1) move the patches around in the GUS's memory, or 2)
  178. preallocate certain number of slots (configurable, eg via 'GMOS -b32'
  179. for 32K max for each patch) for patches.
  180.  
  181. .tc
  182.  
  183. ------------------------------
  184.  
  185. Date: 28 Mar 93  0:01 -0800
  186. From: Thomas Wong <twong@civil.ubc.ca>
  187. Message-Id: <3321*twong@civil.ubc.ca>
  188. Subject: mt32.zip on epas
  189. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  190.  
  191. Yup. I made a booboo. I have now moved mt32.zip from ....sound/patches/util
  192. to .....sound/midi/files. Thanks for catching that. I haven't made the
  193. change on wuarchive yet though.
  194.  
  195. If you find any errors on the ftp sites, please either post it or let
  196. me know. Thanks.
  197.  
  198.  
  199. Thomas.
  200.  
  201. ------------------------------
  202.  
  203. Date: Sun, 28 Mar 93 13:58:41 EST
  204. From: pccmoddan@aol.com
  205. Message-Id: <9303281358.tn10481@aol.com>
  206. Subject: Ultrasound Daily Digest V...
  207. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  208.  
  209. John Smith wrote:
  210. > I know that a lot of people have said that its OK to put both a 
  211. > GUS and SB in the same machine. I also know that some people 
  212. > have had some success doing just that.  However, it is really 
  213. > not a good idea. There are some very solid hardware reasons NOT 
  214. > to do this. Even though you can move the I/O address and IRQ that 
  215. > SBOS uses so that it will not conflict with the SB, you cannot 
  216. > move the DMA channel. SBOS and the SB both use DMA channel > 1. 
  217.  
  218. I use both an SB Pro (set to Irq 7, address 220, and DMA channel 1) and a GUS
  219. (set to Irqs 5 and 11, address 240 and DMA channel 3) in the same machine (a
  220. 486DX-33 (with an >opti< chipset) with absolutely no problems, including when
  221.  
  222.  
  223. testing software with SBOS.
  224. (When SBOS is run software completely ignores the SB Pro and detects SBOS as 
  225. an SB perfectly). But this would not apply to most people. However, if all
  226. that conflicts is SBOS and the SB, what is the problem? Almost anyone with
  227. both a GUS and and SB in the same machine would not be using SBOS at all, so
  228. it seems they wouldn't have any problems, just as I haven't. I've talked to
  229. many more people who are running both in the same machine with no problems
  230. than people who tried and had problems. Short of having hardware SB emulation
  231. on the GUS, there's no better way to run SB software. 
  232.  
  233. - Dan Nicholson
  234.  
  235. ________________________________________________________
  236. Dan Nicholson    -    PCkS Associates - (908)964-8066 - ModDan
  237.                               553 Thoreau Terr. 
  238.                               Union, NJ 07083
  239. ________________________________________________________
  240.                
  241.                    Support RAM based wavetable synthesis.
  242. ________________________________________________________
  243.  
  244. ------------------------------
  245.  
  246. Date: 28-MAR-1993 13:41:01.41
  247. From: Richard Wyckoff <RWYCKOFF@EAGLE.WESLEYAN.EDU>
  248. Message-Id: <01GWCEV265IO8Y5QQE@EAGLE.WESLEYAN.EDU>
  249. Subject: Ultrasound Daily Digest V2 #83
  250. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  251.  
  252. [A word about Xwing, again...]
  253. > From: Eric N. Liao <liaoe@aero.org>
  254. > Subject: GMOS
  255.  
  256. > Anyway, next time I run X-Wing, I will try the MPU-401 setting.
  257. > Also, I found that John Smith's solution to game slowdown during digitized sfx
  258. > works perfectly.  
  259.     I find this a little ironic, considering that I (and others) posted
  260. this solution long before John got around to it...well, it's "John Smith's
  261. solution" now, I guess :)  [actually, I got one supportive email when I posted
  262. it, so I'm not *really* complaining.]
  263.  
  264. > You have to shut off music, and then (at least for me) there
  265. > is no longer that slowdown associated with firing lasers.  I'm not sure why
  266. > so many people are blaming Lucasarts...seems more like a problem with
  267. > Creative Labs to me.  Look, the SB1.5 actually DROPPED the on/board CMS stereo
  268. > chips (buy them separately for $30.)  Like they really cost that much.  This
  269. > gives you an idea of Creative Labs' early products.
  270.     I don't think much of Creative Labs (anymore) but I'm still more
  271. than convinced that the slowdown is due to poor programming, not 'slow DAC'- 
  272. WC II played digitized sound and FM music simultaneously without the HUGE
  273. performance hit in Xwing - it's possible, of course, that they had to use
  274. a crummy digitized sound output routine in order to get the otherwise incredibly
  275. high frame rate, but still...
  276.  
  277.  
  278.     Also, while those CMS chips might not have cost $30, they certainly
  279. weren't crap, and it's a real shame that Creative Labs stopped including
  280. them, or we might have had stereo music in games years ago.  I know that
  281. the difference in music in Ultima 6 and Sorcerian with Game Blaster (CMS)
  282. vs Adlib was *very* noticeable, but it's the old lowest common denominator
  283. again. *sigh*
  284.  
  285.  
  286. [And now for something completely different - sample noise]
  287. > From: "Loking... Searching" <mcng@undergrad.math.uwaterloo.ca>
  288. > Subject: Gus Notes and 16 bit Daughter Card and NOISE!!
  289.  
  290.  
  291. > Another question regarding sound quality,  I've read some where, I believe from
  292. > Phat, that the GUS is one of the most "quietest" sound cards out there.   Now, i
  293. > f I get the 16 bit record daughterboard, which I would like to very much, will t
  294. > he samples come (%5 tolerance at the most! ) to CD quality..  I know this is adv
  295. > ertise as so.  But the fact is. that There is noise!
  296.  
  297. > I'd like also to know the final answer to the question of why there is
  298. > noise when recording a NULL signal...  and the solution.
  299.  
  300.     I'm quite concerned about this issue, too.  I have observed two things
  301. about sample noise: 1) 8-bit samples (.WAV format, mostly) have an enourmous
  302. amount of noise in them.  I have tested this by generating a 16-bit raw sample
  303. in the OS/2 beta of Csound which I am testing, and then using Wave for Windows
  304. to turn it into both an 8-bit and a 16-bit .WAV file.  The 8-bit sample always
  305. sounds like there is a noisy fan recorded in the background; the 16-bit sample
  306. is as clean as you could hope.  I wonder if this is another example of just
  307. plain crappy Microsoft code?  8-bit sound naturally can't reproduce the full
  308. frequency spectrum of a sample, but it shouldn't induce noise.   This may
  309. explain the null sample noise problem.
  310.  
  311.     Observation 2) When the GUS microphone in is turned ON (as it is
  312. by default) there is a TON of noise all the time.  Now, I have the worst
  313. amplifier in the world, so I can't say for certain if turning OFF the mic
  314. will eliminate all the noise, and I haven't bothered making any recordings
  315. off of CD through the line in, because of this Windows 8-bit .WAV problem
  316. that I've already discussed.  I will say that before I started fooling around
  317. with gusmixer, I could hear video writes and disk writes (even though my video
  318. card is three or four slots away from the GUS) and now I don't.
  319.  
  320.     My projected solutions, for the arrival of the 16-bit daughtercard:
  321. NEVER use the mic in.  If you are sampling for music or multimedia, you won't 
  322. get acceptable quality through a mic anyway, and you're going to record all 
  323. the background noise that your computer generates (fan, etc) even if you can 
  324. isolate the electronic interference.  If you need voice, tape it in a quiet
  325. room, then run the tape into the line in.  Hopefully, all of this will cut
  326. the noise down to an unnoticeable minimum.  
  327. --
  328.  Multimedia: You mean I could fill up my hard disk annotating spreadsheets 
  329.  with digitized voice when I'd been foolishly conserving space by using text?
  330.  Why didn't *I* think of that!  Bill Gates, my hero!
  331.  
  332.  
  333.                **Richard Wyckoff**RWYCKOFF@EAGLE.WESLEYAN.EDU**
  334.  
  335. ------------------------------
  336.  
  337. Date: Sun, 28 Mar 93 00:17 MST
  338. From: <AUBEN%ASUACVAX.BITNET@VM.USC.EDU>
  339. Message-Id: <9303280718.AA02700@orca.es.com>
  340. Subject: Zone 66 - Parity Errors
  341. To: Ultrasound Daily Digest <ultrasound@dsd.es.com>
  342.  
  343. Has anyone else had trouble running Zone 66?  When I first tried it, it gave me
  344. one of the infamous "off board parity errors" and promptly locked up.  It was on
  345. ly by disabling the parity checking in my CMOS settings that I got it to work.
  346. I just want to find out if there's a valid, but harmless, reason for it, or if
  347. something's actually wrong with the card.  Could this be an example of a 16-bit
  348. DMA problem?  That'll be the next thing I try.
  349.  
  350. Oh, on the subject of Zone 66, is there any way to shut off the Line In while pl
  351. aying?  I ended up unplugging mine, as the mixers didn't work.
  352.  
  353. --John
  354.  
  355. (pccjohnb@aol.com)
  356.  
  357. ------------------------------
  358.  
  359. End of Ultrasound Daily Digest V2 #84
  360. ******************************
  361.  
  362. Digest Address:                                        ultrasound@dsd.es.com
  363.                                                 To post to tomorrow's digest
  364.  
  365. Request Server Address:                        ultrasound-request@dsd.es.com
  366.                                 To subscribe, unsubscribe, and request files
  367.  
  368. Owner Address:                                   ultrasound-owner@dsd.es.com
  369.                                To contact a human if the server has troubles
  370.  
  371. FTP Sites:                archive.epas.utoronto.ca         pub/pc/ultrasound
  372.                           wuarchive.wustl.edu       systems/msdos/ultrasound
  373.  
  374.  
  375.